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Abstract 

This  paper  presents  the  interim  results  of 
work  by  the  Space  and  Naval  Warfare 
Systems  Center  San  Diego  (SPAWAR)  to 
increase  the  speed  of  Command  and  Control 
(C2)  operations  in  the  Naval  Force 
Deployment  Planning  Process1.  SPAWAR 
has  fielded  a  Web-based  employment 
scheduling  and  deployment  planning  system 
for  the  Navy  called  WebSked  Distributed 
Services.  The  Chief  of  Naval  Operations 
designated  it  the  sole  employment  scheduling 
system  for  the  Navy.  Work  is  currently 
underway  to  integrate  additional  aspects  of 
the  deployment  and  crisis  response  planning 
processes  into  this  automated  architecture 
and  thus  increase  speed  of  Command. 

Deployment  planning  produces  the  Navy’s 
Fleet  Response  Plan  (FRP).  The  FRP  helps 
meet  quantitative  readiness  goals  by  focusing 
on  finding  the  force  allocation  combinations 


1  This  work  was  sponsored  by  the  Program  Executive 
Office,  C4I  and  Space,  PMW- 150 


that  yield  the  optimal  deployment  dates  for 
specific  missions.  The  very  nature  of  FRP 
production  and  its  alteration  during  Crisis 
Response  Planning  is  complex.  Formulation 
of  multiple  options  and  analysis  of 
alternatives  is  a  tractable  problem  for  an 
automated  system  to  support,  but  only  when 
the  parameters  from  external  systems  and 
personnel  are  appropriately  enumerated  and 
brought  together  in  a  single  data  store.  The 
plans  for  this  work  are  discussed  and  the 
resulting  C2  framework  is  presented. 

1  Introduction 

The  Office  of  the  Secretary  of  Defense  issued 
the  Quadrennial  Defense  Review  in  2001  that 
gave  the  requirement  for  military  forces  to  be 
able  to  swiftly  defeat  aggression  in  overlapping 
conflicts  [OSD,  2001].  Part  of  the  Navy’s 
response  to  this  challenge  was  to  create  a  culture 
of  readiness.  Every  aspect  of  operations  is  being 
optimized  make  the  maximum  number  of  units 
and  force  groups  available  for  immediate 
forward  deployment  at  any  time.  The  Fleet 
Response  Plan  (FRP)  concept  was  laid  out  by 
the  Secretary  of  the  Navy  [SECNAV,  2003]  and 
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Figure  1  -  The  Navy  Schedule  Planning  and  Execution  Process  as  Fully  Automated  by  WebSked  DS 


made  into  policy  by  the  Chief  of  Naval 
Operations  in  2003  to  implement  these  readiness 
goals  in  the  Navy  deployment  planning  process. 
The  FRP  helps  meet  certain  quantitative 
readiness  goals  by  focusing  on  finding  the  force 
allocation  combinations  that  yield  the  optimal 
deployment  dates  for  specific  missions. 

The  very  nature  of  FRP  production  and  its 
alteration  during  Crisis  Response  Planning  is 
complex.  Formulation  of  multiple  options  and 
analysis  of  alternatives  is  a  tractable  problem  for 
an  automated  system  to  support,  but  only  when 
the  parameters  from  external  systems  and 
personnel  are  appropriately  enumerated  and 
brought  together  in  a  single  data  store.  The 
results  of  our  ongoing  WebSked  Distributed 
Services  system  development  work  in  this  area 
are  discussed  in  this  paper  and  the  resulting  C2 
framework  is  presented. 

The  Space  and  Naval  Warfare  Systems 
Center  San  Diego  (SPAWAR)  has  fielded  a 
Web-based  employment  scheduling  and 


deployment  planning  system  for  the  Navy  called 
WebSked  Distributed  Services  (WebSked  DS) 
[Ambrosius,  et  al.,  2004],  It  has  been  designated 
by  the  Chief  of  Naval  Operations  (CNO)  as  the 
sole  employment  scheduling  system  for  the 
Navy  [CNO  N3N5,  2004],  Work  is  currently 
underway  to  integrate  additional  aspects  of  the 
deployment  and  crisis  response  planning 
processes  in  this  automated  architecture  and 
thus  increase  speed  of  Command. 

With  the  consolidation  of  all  authoritative 
Navy  ship,  aircraft,  and  amphibious  movement 
schedules  into  a  single  WebSked  DS  data  store 
available  worldwide,  it  has  now  become 
possible  to  integrate  the  entire  Navy  deployment 
planning  process  from  requirements  to  actual 
sailings  into  an  automated  architecture.  The 
Navy  planning  process  is  given  in  Figure  1.  In 
addition,  the  process  of  changing  the  plan  of 
force  projection  in  the  very  near-term  due  to 
emergent  conditions,  known  as  crisis  response 
planning,  can  also  be  incorporated.  The 
integration  of  these  processes  into  an  automated 
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Figure  2  -  The  WebSked  Distributed  Services  Architecture 


C2  architecture  holds  great  promise  for 
shortening  the  time  required  for  deliberative  and 
reactive  planning  cycles  and  thus  enhancing 
Command  and  Control  capabilities  for  the 
Navy. 

1.1  WebSked  DS  Overview 

SPAWAR  first  deployed  WebSked  DS  in 
June  of  2002.  It  is  an  entirely  web  browser- 
based  system  for  scheduling  and  planning  the 
movement  of  major  maritime  assets,  such  as 
ships,  squadrons,  and  other  embarkable  Units.  It 
operates  on  the  Secure  Internet  Protocol  Routing 
Network  (SIPRNET)  to  manipulate  and 
distribute  scheduling  data,  most  of  which  is 
classified  at  the  SECRET  or  CONFIDENTIAL 
level.  Its  major  end-user  features  include: 


•  Deployment  plan/Fleet  Response  Plan 
editing  and  maintenance  (Force  Allocations) 

•  Integrated  schedule  picture  available  from 
any  server  world-wide 

Since  WebSked  DS  became  the  authoritative 
Navy  data  source  for  Unit  employment 
schedules  the  need  for  other  maritime  and  Joint 
systems  to  pull  schedule  data  from  and  submit 
proposed  changes  directly  into  WebSked  DS  as 
part  of  a  Service  Oriented  Architecture  (SOA) 
has  emerged.  Therefore  WebSked  DS  features 
an  encrypted  Simple  Object  Access  Protocol 
(SOAP)-based  service  utilizing  Extensible 
Markup  Language  (XML)  for  approved 
schedule  retrieval,  and  bi-directional  schedule 
transfer  with  other  authenticated  systems. 


•  Visual  employment  scheduling 

•  Optional  offline  editing  and  printing  on  the 
desktop 

•  Automated  schedule  workflow 

•  Mission  needs  brokering  (Services) 


The  system  architecture  is  shown  in  Figure  2. 
It  consists  of  twelve  servers  with  J2EE  and 
Sybase  database  support  at  six  physical  Fleet 
sites  around  the  world  and  has  the  capacity  to 
expand  to  more  than  50  servers  as  needed.  The 
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Figure  3  -  The  Fleet  Response  Plan  and  Relationship  to  Deployment  Options 


system  incrementally  replicates  data  among  all 
servers  to  maintain  a  consistent  scheduling 
picture  (~3  seconds  on-site,  30  minutes  between 
sites)  everywhere. 

1.2  Deployment  Planning  Overview 

Deployment  planning  is  defined  as 
operational  planning  directed  toward  the 
movement  of  forces  and  sustainment  resources 
from  their  original  locations  to  a  specific 
operational  area  for  conducting  the  joint 
operations  contemplated  in  a  given  plan  [DOD 
2005].  It  encompasses  all  activities  from  origin 
or  home  station  through  destination,  specifically 
including  intra-continental  United  States,  inter¬ 
theater,  and  intra-theater  movement  legs, 
staging  areas,  and  holding  areas. 

Deployments  of  major  Navy  force  groups 
must  follow  the  Navy  nominal  27-month 
deployment  cycle.  This  cycle  is  illustrated  in 
Figure  3.  The  Figure  shows  the  approximate 
times  targeted  for  achievement  of  the  Fleet 
Response  Plan  states  of  Non-Deployable, 
Emergency  Surgeable,  Surgeable,  Deployable, 


and  Sustainment.  It  also  shows  that  combat 
capabilities  and  deployment  options  are  limited 
in  some  FRP  states. 

The  deployment  planning  process  may  be 
broken  down  into  three  phases:  data  gathering, 
planning,  and  execution.  Data  gathering  pulls 
together  the  authoritative  information  a  planner 
must  have  prior  to  starting  the  planning  process. 
Planning  is  the  blending  of  requirements, 
inventory,  and  policy  to  produce  a  series  of 
options  to  meet  the  requirements.  Execution  is 
the  selection  and  tasking  of  a  plan  for 
implementation. 

1.2.1  Data  Gathering 

Navy  deployment  planners  report  that  the 
single  most  time-consuming  part  of  deployment 
planning  is  gathering  and  manually  entering  the 
comprehensive  information  required  to 
understand  all  the  requirements  to  be  satisfied 
and  the  scheduling  constraints  of  the  units  and 
personnel  involved.  Information  is  gathered  in 
the  following  areas: 


4 


Leaehd 

CtiWOA  |  Hw2004  \  Deo  2004  |  JahOTS  ]  Feb  2005  |  Mar  5005  |  APr20C5 

Ma y2005  |  Juft.2005  |  Jul  2005  [  Aug2005  |  Sep  2005 

f3  HqIitNs-iS?  Msibel 5 I12I13I20I2  Jo  hel23teoleli3l2ol27le  halzo^tahofiT^ 

i 1slisbsbol  5  Ii2li9[2aj3  MMbskluhsbs 

A  LINCOLN  CSG 

A  LINCOLN  CSG  (TGM-004) 

DEPLOY -WESTERN  PACIFIC  DEPLOYABLE  |  |  EMERG  SURGE  ::  EMERG  SURGE  ]  SURGEABLE  :  ■  SURGEABLE 

C  VINSON  CSG 


|sUfi&EABLl|  |t)  Nf|jSc 


C  VINSON  CSG  (TG05005) 

ill  ins 'aBM 

DEPLOY  :  CEMTCOM  AQR  :  DEPLOYABLE 


ASGN  ASGN  .  GENICOM  AQR  :  COMFIFTHFLT  ASGM  :  M 

ASGN  :  MLTSL 


COK:  NEWPORT  NEWS 


SURGEABLE  : 


DD  EISENHOWER 

CSG 


DB  ESSEN  MOWER  CSO  (T  005-00 1) 


ROS  ;  ; ROS 


PSA  ;  NORFOLK  VA  ;  REFIT  BASIC  ;  ; 


HS  TRUMAN  CSG 


D E FLOY  CENTCQM  APR  DEPLOYABLE 


SURGEABLE  :  :  SURGEABLE 


Ml  ASGN  : 

ASGH  :  GENICOM  AOR  :  CTF  050 

■  ASGN  :  M 

1 

JF  KENNEDY  CSG 


JF  KENNEDY  CSG  (TGQ3-002) 


f  DEPLOY  NORTH  ARABIAN  | 

SURGEABLE  :  :  SURGEABLE 

\  ASGN  :  CTF  060  | 

ASGI* 

Ki  T  T Y  HAWK  C  S  6  <T  GQS-OOO) 


KITTY  HAWK  CSG 


SRA : YOKOSUKA : SRF  YOKOSUKA 


DEPLOYABLE  :  PACOM  AOR  :  COMSEVENTHFLT 


± 


J  L 


a  i 


Figure  4  -  Selected  Carrier  Strike  Group  Deployments  in  WebSked  Distributed  Services 


a.  Deployment  requirements  -  A  listing  of 
approved  and  proposed  requests  for  Navy 
assets  to  be  placed  under  the  control  of  a 
combatant  commander. 

b.  Force  structure  -  The  inventory  of  assets 
that  may  be  drawn  from  to  meet  deployment 
requirements. 

c.  Modernization  considerations  -  A  schedule 
of  the  down-times  of  units  that  are  required 
to  be  taken  out  of  service  periodically  to 
have  needed  maintenance  and  modernization 
performed. 

d.  Training  considerations  -  The  training 
required  for  a  unit’s  personnel  to  be  ready  to 
perform  a  specific  mission. 

Modernization  is  a  major  deployment 
planning  factor,  since  these  periods  affect 
shipyard  utilization.  Shipyard  capacity  and 
suitability  are  tightly  constrained,  therefore  the 
ability  to  change  modernization  periods  is 
similarly  difficult. 

Training  is  also  especially  important  to 
planning.  During  down-time  periods  a  unit’s 
ability  to  conduct  its  wartime  mission  will 
degrade.  Upon  completion  of  modernization,  a 
time-to-train  period  is  required  to  regain  war¬ 
fighting  capability. 


The  information  above  is  currently  gathered 
and  entered  into  spreadsheets  and  slides 
manually.  However,  much  of  the  data  gathered 
during  this  phase  is  available  from  electronic 
sources.  The  time  required  for  this  phase  could 
be  substantially  reduced  by  automated  gathering 
and  entry  into  a  planning  database  wherever 
possible. 

1.2.2  Planning 

Once  the  inputs  to  the  deployment  planning 
process  are  brought  together,  they  are  then  used 
to  formulate  one  or  more  options  to  meet  the 
requirements.  This  is  a  highly  creative  process 
that  has  the  following  basic  steps: 

1.  Visualization  -  Layering  requirements, 
assets,  and  considerations  onto  a  single 
display  to  assist  the  planner  in  viewing  the 
big  picture. 

2.  Rule  development  -  Generate  rules  based  on 
dates,  events,  and  locations  that  implement 
Navy  policy  and  procedures  on  asset 
utilization. 

3.  Course  Of  Action  (CO A)  development  - 
The  process  of  blending  force  structure, 
modernization  and  training  considerations  to 
develop  one  or  more  courses  of  action  to 
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meet  the  deployment  requirements.  COA 
development  requires  special  skills  in  the 
following  areas: 

a.  Movement  Planning  -  The  ability  to 
consider  time,  distance,  and  speed  when 
moving  a  unit  from  its  home  staging  area 
to  its  forward  deployed  area. 

b.  Tomahawk  Planning  -  The  ability  to 
plan  the  number  (by  variant)  of 
Tomahawk  missiles  that  each  ship/sub 
shall  deploy  with  to  meet  theater 
requirements. 

c.  Crisis  Planning  -  The  time-sensitive 
planning  for  possible  deployment  of 
forces  and  resources  that  occurs  in 
response  to  an  emerging  situation. 

4.  Plan  Collaboration  -  The  process  of  vetting 
a  COA  with  Navy  Combatant  Commander 
(COCOM)  and  Type  Commander 
(TYCOM)  representatives. 

Crisis  planning  during  COA  development  is 
naturally  time-limited.  A  key  task  during  crisis 
planning  is  the  selection  of  the  best  asset  for  the 
requirement  to  be  filled.  Assets  are  selected 
based  on  availability  and  capability.  Automation 
of  this  best  ship  fit  process  could  decrease  the 
time  required  to  arrive  at  an  acceptable  solution. 

The  collaborative  review  and  correction  of 
plans  is  performed  by  a  group  known  as  the 
TeamSked  community.  This  group  is  made  up 
of  representatives  from  CNO,  Commander, 
Fleet  Forces  Command  (CFFC),  Commander, 
Pacific  Fleet  (CPF),  the  TYCOMs,  the 
numbered  Fleets  (2nd,  3rd,  5th,  6th,  and  7th),  and 
Headquarters  Marine  Corps  (HQMC).  As  the 
members  of  this  community  are  geographically 
spread  throughout  the  world,  much  time  is  spent 
in  the  gathering  and  synchronization  of 
responses  to  COAs  put  out  for  review. 


Automating  this  collaboration  on-line  could 
speed  up  the  workflow  in  this  area. 

1.2.3  Execution 

Once  a  package  of  COAs  have  been  planned 
and  vetted  by  the  TeamSked  community,  they 
are  considered  valid  and  can  then  be  sent  up  the 
chain  of  command  for  approval  and  issued  as 
orders  for  execution.  This  involves  the 
following  actions: 

a.  Plan  approval  -  The  plans  go  through 
increasing  echelons  of  flag  level  review. 
Process  culminates  with  SecDef  decision  to 
proceed  with  one  particular  COA. 

b.  Orders  issuance  -  The  Joint  Staff  issues  a 
Global  Force  Management  (GFM)-Naval 
Presence  Schedule  (NPS)  update  containing 
SecDefs  direction.  The  supporting 
COCOMs  relay  the  change  to  affected  units 
as  a  warning  order  or  prepare  to  deploy 
order  that  triggers  the  transition  of  the  plan 
to  executable  schedules  in  WebSked  DS  (in 
action  C  below).  When  the  time  comes  to 
execute  the  plan  (sometime  months  after 
approval)  a  deployment  order  is  issued  to 
execute  the  employment  schedules  already 
approved  within  WebSked  DS. 

c.  Transition  of  plan  to  a  schedule  -  The 
SecDef-approved  COA  is  entered  as  a  Force 
Allocation  schedule  into  WebSked  DS.  An 
example  of  carrier  deployments  given  as 
Force  Allocation  schedules  is  given  in 
Figure  4.  The  subsequent  warning  or  prepare 
to  deploy  orders  authorize  the  affected  Units 
to  log  onto  WebSked  DS  and  update  their 
employment  schedules  using  the  Force 
Allocation  schedule  already  populated  in 
WebSked  DS.  Units  then  add  pre¬ 
deployment  activities  into  WebSked  DS  to 
complete  the  COA  solution.  Compliance  of 
unit  employment  schedules  to  the  COA  is 
automatically  checked  and  reported  on  by 
WebSked  DS. 
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Figure  5  -  Major  Navy  Deployment  Changes  Mid-Year  2004 


2  The  Need  for  Automated  Deployment 
Planning 

As  Force  Structure  in  the  Navy  has  declined 
from  529  ships  in  1991  to  281  ships  today  the 
operating  tempo  has  grown  due  to  the  many 
factors,  including  the  Global  War  On  Terror 
(GWOT),  Maritime  Homeland  Security  (MHS), 
and  Maritime  Homeland  Defense  (MHD).  With 
the  Navy  being  asked  to  do  more  with  less,  it  is 
crucial  that  the  operational  planners  be  provided 
the  tools  to  be  able  to  quickly  model  the  impacts 
of  a  Request  For  Forces  (RFF)  or  change  to  the 
Global  Naval  Force  Presence  Policy  (GNFPP) 
on  the  current  Fleet  lay  down  and  its  ability  to 
support  and  sustain  the  requirement. 

2.1  Deployment  Planning  Case  Study 

The  following  case  study  was  drawn  from 
real  world  events  in  during  the  last  half  of  year 
2004.  In  order  for  it  to  be  unclassified,  actual 
impact  statements  have  been  modified.  It 
illustrates  the  complex  nature  of  deployment 
planning  and  the  many  factors  involved. 

2.1.1  USS  Kitty  Hawk  Backfill 

The  2004  Global  Naval  Force  Presence 
Schedule  (GNFPS)  was  originally  approved 
with  the  aircraft  carrier  USS  Kitty  Hawk 


providing  theater  presence  in  the  Pacific 
Command  (PACOM)  Area  of  Responsibility 
(AOR).  However,  due  to  certain  emergent 
theater  concerns,  PACOM  issued  a  Request  For 
Forces  for  another  carrier  to  backfill  the  Kitty 
Hawk. 

This  RFF  started  a  crisis  response 
deployment  planning  cycle.  Several  initial 
CO  As  were  developed  by  the  TeamSked 
community  in  a  collaborative  process  taking 
into  account  operational  availability  of  the 
carrier  force  structure,  effects  on  the  long  range 
operational  and  maintenance  schedules,  training 
requirements,  and  personnel  tempo  policies. 

Although  the  Central  Command 
(CENTCOM)  AOR  is  geographically  close  to 
the  PACOM  AOR,  CENTCOM  demands  in 
supporting  Operation  Iraqi  Freedom  (OIF) 
would  make  sourcing  an  additional  carrier  to 
PACOM  from  there  a  real  challenge.  Drawing  a 
carrier  from  CENTCOM  to  give  to  PACOM 
would  just  move  the  problem  to  another  AOR. 
If  a  CENTCOM  carrier  was  lost  (used  in  the 
backfdl  of  Kitty  Hawk),  there  were  the 
following  options: 
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a.  The  Air  Force  could  deploy  forces  to 
cover  the  loss. 

b.  Another  carrier  deployment  could  be 
extended  beyond  6  months  (this  is  a  policy 
problem). 

c.  A  non-deployed  carrier  that  had  not 
completed  all  its  training  requirements  (it  would 
not  be  fully  mission  capable  to  fight  a  major 
conflict)  could  be  brought  in. 

d.  A  combination  of  the  options  above. 

The  deployment  planning  cycle  proceeded  as 
described  in  Section  1.2  above.  Lengthy  delays 
in  the  planning  cycle  were  caused  by  a  lack  of 
input  from  all  Commands.  There  was  no  system 
in  place  to  track  who  replied  and  to  capture  the 
concurrences  or  rejections  of  the  COAs. 
Timeliness  of  replies  was  up  to  the  respondent. 
Group  collaboration  was  limited  to  the  group 
respondents  chose  to  email  their  replies  to. 
Further,  no  graphical  means  to  incorporate 
suggested  changes  was  available.  Thus, 
TeamSked  members  were  sometime  required  to 
evaluate  suggestions  based  on  a  notional 
concept  of  them  alone  and  updates  were  the 
responsibility  of  a  single  individual. 

Fifteen  courses  of  action  were  eventually 
produced  and  reviewed  before  the  three  best 
solutions  were  picked  by  consensus.  These 
COAs  were  determined  to  be  valid  by  the 
TeamSked  participants,  fully  annotated  for  the 
impacts  they  would  cause,  and  moved  up  the 
chain  of  command.  One  solution  was  eventually 
put  forth  for  SecDef  consideration.  This  COA 
solution  proposed  “surging”  (early  deployment) 
of  the  carrier  USS  Lincoln  to  fill  the  presence 
gap  in  PACOM.  In  mid-2004,  SecDef  signed 
the  order  directing  the  execution  of  this  new 
plan  for  use  of  Navy  forces.  Navy  units  then 
updated  their  employment  schedules  in 
WebSked  DS  to  reflect  this  new  deployment 
order. 


2.1.2  Frequent  Change  in  2004 

The  USS  Kitty  Hawk  backfill  example  above 
illustrates  that  many  courses  of  action  may  have 
to  be  generated,  examined  for  impact  and  fully 
reviewed  by  many  stakeholders  to  eventually 
arrive  at  the  solution  for  a  single  planning  cycle 
and  thus  change  the  Navy’s  Fleet  Response 
Plan.  However,  this  example  was  just  one  of 
many  change  cycles  that  occurred  throughout 
the  planning  year  2004. 

For  example,  four  major  changes  occurred  in 
the  last  half  of  year  2004.  These  changes  are 
shown  in  Figure  5.  Before  the  Kitty  Hawk 
backfill  request  (Section  2.1.1)  was  received  a 
deployment  planning  cycle  was  executed  to 
study  the  early  decommissioning  of  the  carrier 
USS  John  F.  Kennedy.  This  study  required 
significant  COA  development  and  review  but 
was  never  approved  for  execution.  It  is  currently 
under  on-going  study.  The  Kitty  Hawk  backfill 
request  was  received  and  resulted  in  fifteen 
COAs  being  generated  and  reviewed  before  a 
final  solution,  the  early  deployment  of  the  USS 
Lincoln,  was  chosen  and  approved.  Not  long 
after  that,  Joint  Forces  Command  (JFCOM) 
relayed  an  RFF  to  the  Navy  to  double  the 
carrier  presence  in  EUCOM  in  2006.  This 
initiated  another  deployment  planning  cycle. 
After  COA  development  and  review,  impacts 
were  deemed  to  be  too  severe  and  this  request 
was  determined  to  be  infeasible.  Finally,  on 
December  26,  2004,  a  massive  Tsunami  (caused 
by  the  Sumatra-Andaman  earthquake)  hit 
several  countries  on  the  Indian  Ocean  resulting 
in  enormous  devastation  and  loss  of  life.  Crisis 
response  deployment  planning  was  immediately 
begun  and  COAs  quickly  developed,  leading  to 
the  diversion  of  the  Bon  Homme  Richard 
Expeditionary  Strike  Group  (ESG)  from  its 
transit  to  the  Persian  Gulf  into  disaster  relief. 
The  deployment  of  the  carrier  USS  Lincoln  was 
also  extended  to  provide  support. 

From  this  example  it  can  be  seen  that  the 
approved  Navy  deployment  plan  changes 
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frequently  due  to  future  planning  and  emergent 
requirement.  Both  deliberate  planning  and  crisis 
response  planning  cycles  are  executed 
throughout  the  year. 

2.2  Benefits  of  Automated  Deployment 
Planning 

Full  implementation  of  automated 
deployment  planning  within  the  WebSked  DS 
scheduling  system  as  shown  in  Figure  1  could 
provide  a  remarkable  improvement  in  the  speed 
of  command  in  deployment  re-planning 
operations.  The  reasons  for  this  are  described 
along  with  the  deployment  process  in  Sections 
1.2.1,  1.2.2,  and  1.2.3. 


Table  1:  Comparison  of  Current  and  Expected 
Planning  Times _ _ _ 


Deployment 

Planning 

Phase/Step 

Time 

Current 

(Days) 

Time 

Automated 

(Days) 

Data  Gathering 

Research 

Current  Plans 

2.0 

1.0 

Calculate  Unit 
Availability 

2.0 

0.25 

Manual  Data 

Entry 

1.5 

0.25 

Planning 

Plan 

Development 

4.5 

1.5 

Course  Of 

Action  Analysis 

4.5 

2.5 

Collaboration 

6.0 

3.0 

Execution 

Order  Issuance 

5.0 

5.0 

Plan  Transition 

10.0 

3.5 

Totals 

35.5 

17.0 

Automation  of  the  employment  scheduling 
process  (day-to-day  employment  of  units)  by  the 
current  WebSked  DS  system  has  already  shown 
the  kind  of  time  reduction  in  planning  business 
process  that  is  possible  for  this  area.  WebSked 
DS  was  shown  to  have  brought  the  schedule 


generation  and  approval  process  timeline  from 
weeks  to  days  [Ambrosius,  et  al.,  2004], 

A  comparison  of  the  actual  planning  times 
for  the  components  of  the  USS  Kitty  Hawk 
backfill  planning  cycle  (given  in  Section  2.1.1) 
to  expected  new  planning  times  once  fully 
automated  within  WebSked  DS  are  shown  in 
Table  1.  The  new  times  are  based  on  interviews 
with  Navy  deployment  planners  and  experience 
in  automation  of  similar  processes  within 
current  WebSked  DS  modules. 

Table  1  shows  that  planning  time  for  the  USS 
Kitty  Hawk  backfill  could  be  reduced  as  much 
as  53%  (18.5  days)  through  automation.  The 
time  for  planning  cycles  varies  with  the 
complexity  of  the  request.  Still,  ten  similar 
deployment  planning  cycles  were  carried  out  in 
2004  (one  rotational,  six  RFF,  and  3  smaller  re¬ 
planning).  If  they  together  had  an  average 
complexity  level  of  the  USS  Kitty  Hawk 
example  (this  is  quite  possible  in  any  given 
year),  possibly  188  planning  days  might  have 
been  able  to  be  saved  through  automation. 

3  Implementation  of  the  WebSked  DS 
Deployment  Planning  Solution 

The  Force  Allocation  module  of  WebSked 
DS  has  already  been  fielded  operationally  to 
house  and  manage  the  Navy’s  approved  Fleet 
Response  Plan.  Current  work  on  WebSked  DS 
version  2.5  will  provide  the  Initial  Operating 
Capability  (IOC)  of  Deployment  Planning, 
which  builds  the  Fleet  Response  Plan.  This 
deployment  planning  module  of  WebSked  DS  is 
called  WebSlider2  (sliding  graphical  controls). 

3.1  Features  of  the  WebSlider  Module 

The  requirements  of  the  Navy  deployment 
planning  process  described  in  Section  1.2  have 
caused  the  WebSlider  Module  of  WebSked  DS 
to  be  designed  to  provide  the  following 
capabilities: 


2  Based  in  part  on  original  work  for  the  U.S.  Navy  by 
Dr.  Stuart  Dunn  at  the  Center  For  Naval  Analysis 
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Figure  6  -  WebSlider  Deployment  Desktop  Application  Utilizing  Web  Services 


a.  The  ability  to  specify  presence  requirements 
for  Carrier  Strike  Groups  (CSGs), 
Expeditionary  Strike  Groups  (ESGs),  and 
Surface  Strike  Groups  (SSGs)  by  theater  of 
operation  and  effective  dates. 

b.  A  collaborative  workspace  to  manage 
Request  for  Forces  and  Capabilities 
(RFF/RFCs)  that  identifies  whether  the 
request  is  deliberative  or  crisis,  provides  its 
status,  and  assists  in  identifying  units 
available  to  satisfy  the  request  to  assist  in 
developing  modifications  to  the  current 
COA. 

c.  The  ability  to  manage  rules  for  determining 
notional  FRP  states,  and  rules  to  use  during 
schedule  sourcing  validation. 

d.  The  capability  to  load  maintenance,  Navy 
Mission  Essential  Task  List  (NMETL), 
Readiness,  force  composition,  and  force 
allocation  data  for  selected  units  from 
WebSked  DS  to  create  CO  As. 

e.  A  graphical,  easy  to  use  interface  that  allows 
TeamSked  community  members  to  easily 
identify  and  schedule  units,  add  events, 
create  presentations,  import  and  export  data, 
and  validate  the  sourcing  solution  of  COAs. 


f.  Provide  a  collaborative  workspace  to  post 
and  download  COAs  for  review  and 
concurrence,  provide  comments,  and 
manage  unit  sourcing  solutions  to  satisfy  the 
COA. 

g.  Provide  the  capability  to  update  force 
allocation  data  based  on  the  sourcing  data 
from  SecDef  approved  COAs. 

h.  Provide  the  capability  to  validate  sourcing 
data  against  the  scheduling  rules  (turnaround 
ratio,  nights  out  of  home  port,  operational 
tempo,  retention,  etc.),  and  identify  and 
remark  on  any  violations. 

i.  Manage  access  to  the  workspace  and 
modification  of  COAs  and  sourcing  data. 

3.2  Architecture  Considerations 

The  WebSlider  capabilities  being  developed 
for  the  deployment  planning  community  are 
being  designed  using  the  evolving  Joint 
Command  and  Control  (JC2)  system 
architecture  guidelines  and  concepts.  WebSked 
DS  implements  a  Service  Oriented  Architecture 
(SOA)  that  will  allow  it  to  more  easily  adopt  the 
JC2  platform  as  it  is  rolled  out.  WebSked  DS 
publishes  and  accepts  data  using  Simple  Object 
Access  Protocol  (SOAP)  web  services  that  use 
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Extensible  Markup  Language  (XML).  It  is  also 
a  customer  of  web  services  provided  by  other 
systems  to  capture  maintenance,  training,  and 
readiness  information  from  the  appropriate 
authoritative  data  sources.  Every  effort  has  been 
made  to  abstract  the  system  behind  a  small 
number  of  well-defined  network  interfaces. 

In  keeping  with  the  SOA  concept,  the 
visualization  component  of  the  WebSlider 
module  is  planned  for  implementation  as  a 
desktop  application  (for  speed  and  local  control) 
connected  to  WebSked  DS  and  other  data 
sources  via  web  services  (for  easy  data 
exchange).  Figure  6  shows  the  planned 
architecture.  Courses  of  action  will  be  posted  to 
the  WebSked  DS  website  for  collaborative 
review  by  the  TeamSked  community. 
TeamSked  members  will  be  able  to  vote  on  and 
make  adjustments  to  proposed  courses  of  action. 
The  deployment  planning  facilitator  will  be  able 
to  monitor  and  manage  the  CO  As  going  through 
review.  Once  COAs  are  approved  as 
deployment  orders,  the  execution  component  of 
the  WebSlider  module  (server-based)  will  move 
the  new  deployment  plan  into  the  WebSked  DS 
Force  Allocation  module  as  the  new  Fleet 
Response  Plan.  The  Force  Allocation  and 
Employment  scheduling  modules  then 
communicate  to  ensure  compliant  employment 
schedules  are  generated  from  the  Fleet  Response 
Plan. 

4  Summary  and  Conclusions 

This  paper  has  shown  that  deployment 
planning  is  a  complex  process  that  is  ripe  for 
automation.  The  origins  of  the  Fleet  Response 
Plan  were  discussed  (Section  1)  and  its 
relationship  to  deployment  planning  given.  The 
phases  of  deployment  planning  itself  were 
discussed  (Section  1.2)  and  the  many  external 
parameters  enumerated  (Sections  1.2.1,  1.2.2). 
The  need  for  automated  deployment  planning 
due  to  decreasing  inventory  and  increasing 
operational  tempo  was  given  (Section  2).  A 
real-world  case  study  of  the  planning  cycle  was 


outlined  (Section  2.1.1)  and  the  complexity  of 
the  ever-changing  deployment  plan  using  events 
from  the  year  2004  were  described  (Section 
2.1.2).  Areas  where  the  current  planning  process 
could  be  improved  were  given  (Sections  1.2.1, 
1.2.2,  1.2.3,  and  2.1.1). 

Also  described  in  this  paper  was  the 
WebSked  Distributed  Services  system  and  its 
Deployment  Planning  module  currently  under 
construction  to  improve  the  Navy  planning 
process.  An  overview  of  WebSked  DS  was 
given  (Section  1.1).  Features  of  the  WebSked 
DS  Deployment  Planning  module,  known  as 
WebSlider,  were  described  (Section  3.1)  and 
some  architecture  considerations  for  alignment 
with  JC2  and  the  Service-Oriented  Architecture 
were  discussed  (Section  3.2). 

Finally,  the  potential  benefits  from  the 
automation  of  this  process  in  WebSked  DS  were 
described  and  quantified  (Section  2.2).  It  was 
shown  that  the  overall  time  for  the  planning 
cycle  process  in  the  future  may  be  able  to  be  cut 
by  more  than  half  (53%)  bringing  planning  time 
in  one  real-world  example  case  from  over  a 
month  to  about  two  weeks.  This  represents  a 
significant  potential  increase  in  speed  of 
command  for  the  Navy  command  chain  and  will 
contribute  to  more  agile  military  response  once 
deployed. 
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WCBsked 

- ►  DistnbutedServices 


The  Problem 


*  Navy  planners  are  being  asked  to  do  more  with  less 

-  529  ships  in  1991;  only  281  today! 

-  Operational  tempo  increases  due  to  Global  War  On 
Terrorism,  Maritime  Homeland  Security/Defense 

*  Frequency  of  deployment  replanning  is  high  and 
getting  higher 

-  Crisis  Response/Humanitarian  Ops  on  the  rise 

-  Deliberate  planning  to  study  hard  $$  questions  rising 

-  Request  for  Forces  is  migrating  to  Request  for 
Capabilities  (more  options  for  response) 

*  Available  deployment  tools  do  not  provide  sufficient 
Speed  of  Command  to  keep  up  while  staying  agile 
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WCBsked 

- ►  DistnbutedServices 


The  Fleet  Response  Plan  and 
Deployment  Options 


Understanding  the  Fleet  Response  Plan 


Fleet  Response  Plan 


Training  Phase 


Combat  Capability 


Deployment  Options 


Non-Deployable 

Emergency 

Surge 

Surge 

Deployable 

Sustainment 

Maintenance 

Unit 

Level 

Training 

Intermediate 

Level 

Training 

Advance 

Level 

Training 

Deployable 

Sustainment 

Non  Mission  Capable 

Self  Defense 
Limited 
Offensive 

Offensive 

Multi-Unit 

Integration 

Deployable 

Sustainment 

Non-Deployable 

GWOT 
Counter  Drug 

CSG 

ESG 

Deployable 

Sustainment 

FEP 

1  C2X 

JTFX 

J_ 1_ 1_ 1 

01/21/2006 


3 


WCBsked  Selected  Carrier  Strike  Groups  From 

"  2004  (in  WebSked) 
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WCBsked  Deployment  Planning  is  a  Complex  Process 
— ►  Dtfnhutedsemm  (tradeoffs/impacts  are  everything) 


Installs/Maintenance 

Force  Structure 

Readiness 


Ordered  Deployments 

Presence  Requirements 
Navy  Policy  (rules) 


Tomahawk  Requirements 


raining  Plans 


Course  Of  Action 

Team 

Development 

Vetting 

r 


The  Approved  Deployment  Plan 
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WCBsked  Change  Happens  Frequently  and  Fast 

— ►  Distnbuied^mas  (Each  Change  Trigger  the  Planning  Cycle) 


(discarded) 

-i 

/ 

^  Multiple  Tsunami  Response  COAs 

^  A_ 


Approved  Tsunami  Response  Deployment  Plan 


Original  2004  Approved  Deployment  Plan 

Time 
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WCBsked  WebSked  DS  Already  Schedules  the 

- ►  DistnbutedServices  1VT 


•First  Fielded  in  2002;  Designated  by  CNO  as  Navy’s  Authoritative 
_ Employment  Scheduling  System  in  2004 _ 


Features 

•  Visual  Scheduling 

•  Optional  Offline 
Scheduling/Print  (MS  Excel) 

•  Automated  Workflow 

•  Email  Notification 

•  Common  Schedule  Picture 

•  Ad  Hoc  Reporting 

•  Planning  Decision  Aids 

•  Fuel  Planning  and  Estimating 

•  Support  for  Large  Sets  of 
Contingency  Plans  (Emp) 

•  Force  Planning  and  Allocation 

•  Mission  Needs  Brokering 
(Services) 

01/21/2006 


Schedules  Maintained 

•  Global  Naval  Force  Presence 
Schedules 

•  Deployment  Schedules  (Fleet 
Response  Plan) 

•  Contingency  Planning  (Emp) 

•  Modernization  Schedules 

•  Exercise  Schedules 

•  Transit  Schedules 

•  Services  Schedules 

•  Mid  Range  Battle  Group 
Training  Cycle  Schedules 
(import) 

•  Operational  Schedules 

•  Historical  schedules  (last  5  yrs 
of  operational  schedules)  7 
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The  Solution 


•  Complete  the  automation  of  the  Navy  Deployment/Employment 
planning  chain  in  WebSked 

-  Leverage  existing  automation  investment  in  Employment  Sheduling 
and  Fleet  Response  Plan  maintenance 

-  Movement  of  planning  data  from  requirements  to  deployment  plans 
to  employment  schedules  to  execute  is  fast  and  efficient 

•  Develop  the  WebSked  Composeable  Assistant  for  Networked- 
Deployment  Operations  (CAN-DO)  module 

-  Easy  Visual  Course  Of  Action  (COA)  deployment  planning 

•  Quick  to  plan;  Quick  to  change 

-  Electronic  fusion  of  multiple  planning  sources 

•  Eliminate  the  laborious  manual  data  collection  and  entry 

-  Automation  and  enforcement  of  the  COA  review/vetting  process 
among  all  Navy  deployment  planning  stakeholders  (the  TeamSked 
Community) 
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The  Navy  Deployment  Planning 
Distnbutedsemces  Process  (with  WebSkecl  Automation) 
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DistrtbutedServices 
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The  WebSked  Distributed  Services 

Architecture 


Longitudinal 
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Deployment 

Planning 


Employment 

Scheduling 


Mission  Needs 
Brokering 
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Mission  Needs 
Brokering 
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Forward 

Operational 
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WebSked  DS 
J2EE  -  Sybase 


Registration 

Server 


WebSked  DS 

J2EE  -  Sybase 


WebSked  DS 
J'2EE  -  Sybase 


WebSked  DS 
J2EE  “  Sybase 


Data 

Replication 


Pacific  Fleet 
Pearl  Harbor,  HI 


Fleet  Forces  Command 
Norfolk,  VA 


WebSked  DS 
J2EE  -  Sybase 


WebSked  DS 

J2EE  -  Sybase 


WebSked  DS 
J2EE  “  Sybase 


SPAWAR 

San  Diego,  California 


NAVEUR 
Naples,  Italy 


NAVCENT 
Manama,  Bahrain 
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WebSked  Usage,  Approval  Speed, 
and  Fidelity  Improvements 


Schedule  Fidelity  of  USS  Units 
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Speed  Of  Change 
Current  Quarter  Schedules 


Load  Item 

2003 

2005 

Active  Users 

517 

1,268 

Active  Units 

382 

937 

Transactions/Day  (Avg) 

1,228 

4,517 

Transactions/Day  (Peak) 

2,837 

10,43s1 1 
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Expected  Reduction  in  Planning 
Cycle  Time  With  Full  Automation 


•  From  Real-World 
Deployment 
Planning  Mid-2004 

•Kitty  Hawk 
Backfill  RFF 


53%  Reduction 
In  This  Case 


Deployment 
Planning 
Phase.  Step 

Time 

Current 

(Days) 

Time 

Automated 

(Days) 

Data  Gathering 

Research 

Current  Plans 

2.0 

1.0 

Calculate  Unit 
Availability 

2.0 

0.25 

Manual  Data 

Entry 

1.5 

0.25 

Planning  j 

Plan 

Development 

4.5 

1.5/ 

Course  Of 
X^ction  Analysis 

4.5 

2r 

Corporation 

6.0 

/.  0 

Execution  / 

Order  Is  suable 

5.0 

/  5.0 

Plan  Transitions^ 

Totals 

<1  3x5 

17.0 

@10 

Similar 

Cycles/Yr 


Potential 

188 

Planning 
Days  Saved! 
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WCBsked  CAN-DO  Deployment  Planning  in  the 

— "  Distnhutedtenas  WebSked  Services-Oriented  Architecture 


CAN-DO  Builds  On  Existing  WebSked  Web  Services 
_ For  Full  SO  A  Participation _ 
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Conclusion 


*  CAN-DO  is  scheduled  to  deploy  in  2007 

*  CAN-DO  Deployment  Planning  will  complete  the 
automation  of  the  Navy  Deployment/Employment 
Scheduling  chain  (from  requirements  to  sailings) 
in  WebSked  Distributed  Services 

*  Full  automation  shows  the  promise  of  cutting 
deployment  planning  Course  Of  Action  cycles  by 
over  50% 

*  Shorter  planning  cycles  means  increased  Speed 
Of  Command  and  a  more  agile  and  responsive 
Navy! 
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F or  More  Information 


•  Approved  Maritime  Schedules  (Available  to  ANYONE  on  the  SIPRNET) 

-  WebSked  Central  http://websked.spawar.navy.smil.mil 

-  Also  user  help  including  account  creation 

•  WebSked  User  Help  (unclassified) 

-  WebSkedHelp@spawar.navy.mil 

•  WebSked  Project  Manager  -  Stephen  Ambrosius 

-  SPAWARSYSCEN  San  Diego  Code  24226 

-  619-553-6830,  553-6830  (dsn), 

-  stephen.ambrosius@navy.mil: 

-  sla@spawar.navv.smil.mil  (SIPR) 

•  WebSked  Project  Deputy  -  Mike  Moser 

-  SPAWARSYSCEN  San  Diego  Code  24226 

-  619-553-1058,  553-1058  (dsn),  mike.moser@navy.mil 
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